REMARKS 



Claims 1-40 are pending in this Application. 
Reconsideration and further prosecution of the above- identified 
application are respectfully requested in view the accompany 
Request for Continued Examination, and the amendments, and in 
view of the discussion that follows. Claims 1-40 have been 
rejected under 35 U.S.C. §103 (a) as being unpatentable over U.S. 
Patent No. 6,611,590 to Lu et al . in view of U.S. Pat. No. 
6,304,653 to O'Neil et al . and further in view of Barnes et al . 
(U.S. Pat. No. 6,757,731). In response, independent claims 1, 16 
and 31 have been further amended to more precisely clarify the 
invention. After careful review of the claims as amended and the 
cited art, it is believed that the claims are in allowable form 
and therefore a Notice of Allowance is respectfully requested. 

Independent claims 1, 16 and 31 have been amended to call 
for continuously scanning idle input stack locations of a 
protocol stack of the client. Support may be found in par. [0044 
and 0045] of the specification. 

Claims 1-40 have been rejected as obvious over Lu et al . , 
O'Neil et al . , and Barnes et al . Lu et al . is directed to an 
Internet Interface Controller that merely routes calls but as the 
Examiner has observed, does not disclose independently spawning a 
call processing application. 



Similarly, while O'Neil et al . initiates calls, it doesn't 
independently spawn a call processing application with a first 
end of the independently spawned call processing application 
operatively coupled to a predetermined protocol stack of the 
selected agent and with a second end of the independently spawned 
call processing application operatively coupled to a protocol 
stack of the client. Further, as stated by the Examiner, O'Neil 
et al . does not disclose a protocol stack of the agent and 
protocol stack of the client being disposed inside the private 
computer network and wherein communication between the 
predetermined protocol stack of the agent and protocol stack of 
the client operates under a first protocol and communication 
between the protocol stack of the client and the client through 
the public communication network operates under a second 
protocol. Rather, for VoIP calls, the O'Neil et al . system 
operates to "communicate directly with the user through the data 
network via voice telephony" (O'Neil et al . , col. 7, lines 13- 
15). For PSTN calls, the O'Neil et al . system functions to 
"initiate a call to the user and initiate a second call to the 
call assistance device 400 to the telephone network interface 
420, for example, and then bridge the two calls" (O'Neil et al, 
col. 9, lines 30-33). As such, O'Neil et al . operates under a 
single end-to-end protocol for either Internet or PSTN calls. 
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In addition, because O'Neil et al . operates under a single 
protocol, there wouldn't be no use for a protocol stack of the 
agent and protocol stack of the client . . . disposed within the 
private computer network. This is especially true since O'Neil 
et al . preserves the separate nature of data network voice 
telephony and switched circuit voice telephony. In addition, the 
call spawning device discussed at Col. 10, lines 60 to Col. 12, 
line 4 is a device which merely monitors actions of the user 
device 20, and initiates calls without request by the subscriber. 

This does not disclose the claimed independently spawning of a 
call processing application, nor is there any teaching of 
scanning idle input stack locations or coupling a first end to a 
protocol stack of the agent and a second end to the protocol 
stack of the client. 

Barnes et al . discloses interfacing protocol stacks in a 
communications network but does not disclose scanning idle input 
stack locations, and provides no suggestion to combine its 
protocol stacks system with the single end-to-end systems of Lu 
et al. and O'Neil et al . In Barnes et al . , protocol messages 
generated by the first protocol stack 211 is sent to the second 
protocol stack 221 via the VCCT subsystem 270 (Col. 4, lines 50- 
53) and are internally interconnected via the VCCT subsystem 
(Col. 12, lines 26-28). Thus, O'Neil et al . protocol stacks are 
physically connected by a VCCT subsystem not coupled by an 
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independently spawned application operatively coupled to a 
protocol stack of the agent and to the protocol stack of the 
client. Further, O'Neil et al . does not disclose continuously 
scanning idle stack locations, or independently spawning a call 
processing application as claimed. 

Since the combination of Lu et al . , O'Neil et al . and Barnes 
et al. fails to provide any teaching of independently spawning a 
call processing application, continuously scanning idle input 
stack locations, or an independently spawned application 
operatively coupled to the protocol stack of the agent and to the 
protocol stack of the client, the combination fails to teach or 
suggest each and every claim limitation. Because the combination 
fails to teach or suggest each and every claim limitation, the 
claims are distinguishable over the combination of cited 
references. In addition, since O'Neil et al . operates under a 
single protocol, there is no motivation, or suggestion to combine 
Barnes et al . protocol stacks with O'Neil et al . To rely on the 
advantages of the invention as a motivation is merely use of 
hindsight to combine the references. Therefore, the combination 
is believed to be improper, the claims are further 
distinguishable for this reason as well. 

The allowance of claims 1-40 as now presented, is believed 
to be in order and such action is earnestly solicited. Should 
the Examiner be of the opinion that a telephone conference would 
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expedite prosecution of the subject application, he is 
respectfully requested to telephone applicant's undersigned 
attorney. 



March 15, 2006 

WELSH & KATZ, LTD. 

120 South Riverside Plaza 

22nd Floor 

Chicago, Illinois 60606 
(312) 655-1500 



Respectfully submitted, 



WELSH & KATZ, LTD. 
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